P2: README run instructions imply stdio demonstrates tasks flow, but stdio cannot negotiate the tasks extension. Users running the default command will not see the documented task behavior.

Check if this issue is valid — if so, understand the root cause and fix it. At examples/stories/tasks/README.md, line 11:

<comment>README run instructions imply stdio demonstrates tasks flow, but stdio cannot negotiate the tasks extension. Users running the default command will not see the documented task behavior.</comment>

<file context>
@@ -1,24 +1,48 @@
+## Run it
+
+```bash
+# stdio (default — the client spawns the server as a subprocess)
+uv run python -m stories.tasks.client
+
</file context>

P2: intercept_tool_call drops valid BaseModel results to {} before persisting task output. In extension chains this can make tasks/get return an empty result instead of the real tool payload.

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/server/tasks.py, line 171:

<comment>`intercept_tool_call` drops valid `BaseModel` results to `{}` before persisting task output. In extension chains this can make `tasks/get` return an empty `result` instead of the real tool payload.</comment>

<file context>
@@ -0,0 +1,232 @@
+        now = self._clock()
+        task = self._store.create(now, self._default_ttl_ms)
+        result = await call_next(ctx)
+        payload = result if isinstance(result, dict) else {}
+        # A tool result (even isError: true) is a completed task; `failed` is for
+        # JSON-RPC errors, which surface as a raised MCPError, not a result here.
</file context>

P2: A failing tool call leaves a pre-created task permanently stored, causing in-memory task leaks on error paths.

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/server/tasks.py, line 170:

<comment>A failing tool call leaves a pre-created task permanently stored, causing in-memory task leaks on error paths.</comment>

<file context>
@@ -0,0 +1,232 @@
+            return await call_next(ctx)
+        now = self._clock()
+        task = self._store.create(now, self._default_ttl_ms)
+        result = await call_next(ctx)
+        payload = result if isinstance(result, dict) else {}
+        # A tool result (even isError: true) is a completed task; `failed` is for
</file context>

P3: Docs are inconsistent: the Tasks story is documented as implemented/runnable here, but the stories index still labels tasks/ as "not yet implemented".

Check if this issue is valid — if so, understand the root cause and fix it. At examples/stories/tasks/README.md, line 3:

<comment>Docs are inconsistent: the Tasks story is documented as implemented/runnable here, but the stories index still labels `tasks/` as "not yet implemented".</comment>

<file context>
@@ -1,24 +1,48 @@
-`resultType: "task"` envelope, `execution.taskSupport` gating, and `ttlMs`
-fields — so it lands in a separate PR with the conformance `tasks-*` scenarios
-wired in.
+Task-augmented execution (SEP-2663). A client declares the
+`io.modelcontextprotocol/tasks` extension; the server may then answer a
+`tools/call` with a `CreateTaskResult` (carrying a task id) instead of blocking,
</file context>

MISSING_REQUIRED_CLIENT_CAPABILITY redefined as -32003 — schema (and the rest of the SDK) use -32021

The core schema defines MISSING_REQUIRED_CLIENT_CAPABILITY = -32021 (schema.ts L418), and the SDK's own mcp_types.MISSING_REQUIRED_CLIENT_CAPABILITY, the generated MissingRequiredClientCapabilityError.code: Literal[-32021], require_client_extension(), and the shared/inbound.py HTTP-status map all use -32021 for this exact semantic. SEP-2663's prose still prints -32003 in three places, but that predates the spec PR #2907 error-code renumber and was never updated — the schema is the source of truth for codes.

Import the constant from mcp_types (or just call require_client_extension) so _require_tasks_capability() is consistent with the rest of the SDK and the conformance harness; update the module docstring, docs/migration.md, and the test that asserts this code.

_{AI Disclaimer}

InputRequiredResult is augmented into a task and misreported as completed

An InputRequiredResult reaching the interceptor is stored via _store.complete(...) and reported by tasks/get as status: "completed" with the InputRequiredResult inlined as result — but CompletedTask.result for a tools/call task must be a CallToolResult (SEP-2663 §Task Status).

Per SEP-2663 §Task Creation, MRTR exchanges SHOULD resolve synchronously before CreateTaskResult — task status: "input_required" is a separate inputRequests/tasks/update mechanism, not a mapping for InputRequiredResult. So even with the tasks/update loop deferred, the interceptor should inspect payload.get("resultType") and pass an "input_required" result through unchanged (no task created), letting the MRTR loop run on the original request and augmenting only the eventual CallToolResult.

_{AI Disclaimer}

tasks/cancel clobbers terminal status and drops the completed result

tasks/cancel unconditionally overwrites status to "cancelled" with no terminal-state guard, so a completed task regresses to cancelled and the subsequent tasks/get drops the already-computed result (it only inlines on status == "completed"). In this inline core every reachable task is already terminal when tasks/cancel arrives, so this is the handler's only reachable behavior — and test_cancel_task_... snapshots the broken transition.

Terminal statuses (completed/failed/cancelled) should be immutable: SEP-2663 §Cancellation makes cancel cooperative and ack-only, and explicitly allows a task to "reach a terminal status other than cancelled if the work finished before cancellation could take effect." Guard in _handle_cancel (or TaskStore.cancel) and return the empty ack without mutating a terminal task.

_{AI Disclaimer}

Default clock is a fixed epoch stub, not a real wallclock

The default clock is _fixed_clock, a hard-coded "1970-01-01T00:00:00Z" stub — so every server using the documented Tasks() / Tasks(default_ttl_ms=...) emits the Unix epoch for createdAt/lastUpdatedAt on the wire, breaking client TTL-expiry math and making the SEP-2663 timestamp fields useless.

The default should be a real UTC wallclock (e.g. datetime.now(timezone.utc).isoformat()); the fixed clock belongs only in tests. test_create_task_result_uses_default_clock_when_none_injected currently pins the wrong behaviour and will need updating.

_{AI Disclaimer}

Interceptor mishandles exceptional and non-dict call_next outcomes

intercept_tool_call mishandles non-dict and exceptional call_next outcomes (the carry-forward from #3003):

• _store.create() runs before await call_next(ctx) with no try/except, so when the tool call raises (MCPError from an unknown tool or a handler, a ValidationError, cancellation) the task entry leaks in the store at status="working" forever, and the failed status the docstring reserves for JSON-RPC errors is unreachable.
• payload = result if isinstance(result, dict) else {} silently discards a BaseModel (or None) returned by a nested extension interceptor — HandlerResult is BaseModel | dict | None — so the completed task inlines "result": {}.

Wrap call_next in try/except to transition the task to failed (or drop the entry) on error, and serialize a BaseModel result with model_dump(by_alias=True, mode="json", exclude_none=True) (mirror _dump_result in runner.py) instead of replacing it with {}.

_{AI Disclaimer}

[nit] TaskStore grows unboundedly; ttlMs never enforced

TaskStore only ever inserts into _tasks/_results and never removes entries, and the single Tasks instance lives for the server's lifetime — so every augmented tools/call permanently retains its full CallToolResult payload. ttl_ms is stamped on the wire but never enforced server-side, so Tasks(default_ttl_ms=60_000) as shown in the story is advisory-only.

For a long-running HTTP server this is unbounded growth (the store-growth/cleanup concern carried forward from #3003). Worth at least a TTL-based eviction on tasks/get/create, a size bound, or an explicit "no eviction — deferred" note in the module docstring alongside the other deferrals.

_{AI Disclaimer}

[nit] tasks/get / tasks/cancel not version-scoped; legacy clients get the missing-capability error instead of -32601

These bindings omit protocol_versions, so tasks/get/tasks/cancel are served on legacy (≤2025-11-25) connections too. There _require_tasks_capability returns the missing-capability error with a requiredCapabilities: {extensions: ...} payload the client structurally cannot satisfy — since the extension "only exists on the modern wire" (and SEP-2663 §Backward Compatibility says it "is not defined under the 2025-11-25 protocol version"), these should be -32601 instead. Add protocol_versions=frozenset(MODERN_PROTOCOL_VERSIONS) to both bindings.

_{AI Disclaimer}